home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The X-Philes (2nd Revision)
/
The X-Philes Number 1 (1995).iso
/
xphiles
/
psion
/
forg.txt
< prev
next >
Wrap
Text File
|
1994-01-21
|
4KB
|
99 lines
The following is a summarised version of comments made on CIX by Martin
Budden, (Software Engineer at Psion). I'm posting here with his
agreement.
Cheers,
Chris Hennings
======================================================================
I've just had a look at Artworks and it has prompted me to make a few
general comments about writing OPL programs.
There are two types of files that a program can use: the files the
program actually manipulates (I'll call these its data files) (eg
the .DBF file used by the database), and the files the program needs
to run (I'll call these its program files) (eg any bitmaps it needs to
load, or any .OPOs that it loads using LOADM). People seem to have
adopted various solutions to the problem of where to put these files,
I thought I'd offer some 'official' guidance.
The locations of an OPA's data files is determined by the PATH
keyword in the APP ... ENDA structure. Artworks has chosen
\OPD\ARTW. This is a reasonable choice, however we feel that if you
consider your application reasonably serious then you are justified
in creating your own directory off the root, so \ART, \ARTW, or
\ARTWORKS would be equally good, if not preferable choices. We tend
to use 3 character directory names at Psion, but this is just house
style. Use your judgement, if you are writing a small utility OPA
then it is better to use a directory off \OPD.
If your OPA creates any data files (besides the ones that are
shown under the icon) then you should give the user some way of
specifying which drive should be used for these files. It is annoying
to the user if they are always created on M:, since this uses memory
that they may need for running applications (especially true if they
have memory-hungary applications eg the Spreadsheet).
An OPA's program files should NOT be stored in the same place as its
data files: THE USER SHOULD BE ABLE TO DELETE ALL THE FILES IN A
PROGRAM'S DATA DIRECTORY AT ANY TIME. So where should you put the
program files? In a directory of the same name as the OPA - this is
the standard that we have adopted at Psion for any APPs that are
released on SSDs (eg Chess). An example will make this clearer.
Artworks requires a number of .PIC files to run (eg its title screen),
these should be placed in \APP\ARTWORKS, eg
\APP\ARTWORKS\ARTTITLE.PIC
\APP\ARTWORKS\ARTWORKI.PIC
etc, since ARTWORKS.OPA itself resides in \APP\ARTWORKS.OPA. How do
you do this? Again an example should make things clear:
PROC loadbt%:(name$)
LOCAL file$(128),off%(6)
file$ = PARSE$("",CMD$(1),off%())
file$ = LEFT$(file$,off%(5)-1) + "\" + name$
RETURN gLOADBIT(file$)
ENDP
so loadbt%:("ARTTITLE.PIC") will eventually call
gLOADBIT("LOC::A:\APP\ARTWORKS\ARTTITLE.PIC")
(presuming the pack containing Artworks is in drive A).
CMD$(1) is used to get the full path used to start running artworks,
and PARSE$ is used to find the position of the .OPA extension which
is then replaced with "\" + name$.
A similar approach should be used when loading .OPOs with LOADM, or
indeed loading any type of file.
If the above approach is adopted then the user also has the
flexibility of changing the OPA's (or OPO's) directory. For example
I have created a GAMES.ALS which runs any .OPOs in the \GAMES
directory, I have placed Minesweeper in this directory. So
chennings, how about adopting the above convention for Minesweeper?
The above is written in the spirit of constructive criticism, I hope
I have not given the impression that I am knocking Artworks (or
Minesweeper).
======================================================================
If a program is a multi-file app (ie type 2 to type 4) then you have
no choice, it must be distributed as an OPA, since there is no way of
getting the file name onto the command line.
If a program is a 'no file' or 'one file' app (ie type 0 or type 1) then
you have the choice OPO or OPA. Actually you can cheat: distibute
the program as an OPA. This means the user can install it if they
wish. However they can also rename it to *.OPO and copy it to \OPO
and it can then be launched from the OPL bubble. So for instance you
could make Mines an OPA and then the user could put it where they
wished.
If programer's follow the PARSEing rules I outlined above then
should be able to rename their OPAs and copy them to different
directories with no ill effect.